What

Make the support bundle report which configured secrets are set — without ever capturing a value.

Before, the bundle had 5 secret collectors (postgres-password, redis, sandbox-api-key, github-app, keycloak-realm), two of which only checked the secret existed — not which keys inside it were populated. So for a customer using an integration, we couldn't tell from the bundle whether a given credential was actually set.

This adds per-key secret + includeValue: false probes (via a Helm dict/range loop) for the admin-configured / optional secrets — 60 probes total.

Why it's a yes/no without leaking anything

Every config-derived secret key is rendered only when its KOTS value is set ({{- if .Values.config.X }} in charts/openhands-secrets/templates/*). So with includeValue: false, the collector records secretExists / keyExists (booleans) and never the value — keyExists == true ⇔ that credential was configured.

A future bundle will contain e.g. secrets/openhands/bitbucket-data-center-app/bot-token.json → {"secretExists":true,"keyExists":false,...} — the exact signal we were missing while debugging a recent BBDC upgrade (we couldn't tell whether the bot token had been set).

Scope

Covers secrets whose set/unset reflects an admin choice, so the yes/no is meaningful:

• Integration / auth: bitbucket-dc (incl. bot-token), jira-dc, azure-devops, gitlab, slack, github, keycloak-realm SMTP
• LLM: per-provider keys in litellm-env-secrets (shows which provider is configured) + openhands-env-secrets
• Storage / TLS: S3 creds, BYO TLS cert (openhands-tls)
• Baseline infra (kept): postgres / redis / sandbox-api-key

Intentionally omits the always-generated internal secrets (jwt, admin/keycloak-admin passwords, automation-*, plugin-directory, default-api-key, lite-llm-api-key, and the now-defaulted UI_PASSWORD/LITELLM_SALT_KEY) — they'd read set unconditionally and add no signal.

Relationship to #727

Complements (doesn't duplicate) the openhands-config-snapshot env collector from #727. That one execs into the running openhands pod and reports set/unset for a curated SECRET_PRESENCE env list. This PR instead queries the k8s Secret objects directly, which:

1. works when the app pod is down/crashing — exactly when an upgrade-failure bundle gets collected (a pod exec can't run then);
2. covers keys not surfaced as env vars in that pod, and gives per-LLM-provider granularity.

Validation

• Renders cleanly via helm template (valid YAML, deterministic alphabetical order).
• Verified all 60 collectors are includeValue: false, zero includeValue: true, zero value: fields — no secret material can land in a bundle.
• Bumped charts/openhands 0.7.64 → 0.7.66 (0.7.65 is already a release tag) for the chart-template-version-bump check. No Chart.lock / replicated/ pin churn.